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(54) Events as activities in process models of workflow management systems 



(57) The present invention relates to the area of 
workflow management systems (WFMS). WFMS exe- 
cute a multitude of process nrodels consisting of a net- 
work of potentially distributed activities. The cunent 
invention is dedicated to the implementation of events 
within WFMS. The cunenl invention teaches to imple- 
ment events like any other process activity. 
Thus events are implemented as event-activities, a spe- 
cial type of an activity within said WFMS. Such an 
event-activity can manage an event occurring internal or 
external to the WFMS. 

This approach allows to make ail features available to 
common activities also accessible to event activities; 
examples are: input-container ajnd/or output-container, 
control-connectors, data-connectors. notificatk>n-mech- 
anisms, predicates associated to control connectors 
forming transitk>n conditions and many more. A control 
connector leaving an event activity, which optionally 
may be associated with a logk;al predrcate as outgoing 
transitbn conditk)n. allows the WFMS to automatically , 
activate a target activity if said event activity terminated 
after the event has been signaled to said event activity 
and if the outgoing transitk>n condition evaluates to true. 
Similar an incoming control connector, which optionally 
may be associated with a logical predicate as incoming 
transition condition, allows a WFMS to automatically 
activate an event activity if the process activity being the 
source of saki incoming corttrd connecU>r terminated 
and if sad incoming-transition-corKlition evaluates to 
true. 

This invention also teaches to extend the navigator of a 
WFMS by an event management system which inter- 



operates with the navigator to deliver at>ove mentioned 
functionality The event management system encom- 
passes the component of an event monitor acbninister- 
ing awaited events in a awaited event table and further 
administering signaled events in a posted event table. 
The event management system further encompasses 
the component of an event manager maintaining infor- 
mation on events alkywing to verify correctness of an 
event. 
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Description 

1 Baclcground of the Invention 
1 .1 Raid of the Invention 



The present invention relates to the field of compu- 
ter systems acting as workflow management systems 
(WFMS). 

1^ Description and Disadvantages of Prior Art 

A new area of technology with irx^reasing impor- 
tance is the domain of Worlcflow-Management-Sys- 
tems (WWIS). WFMS support the modelling and 
execution of business processes. Business processes 
control which piece of work of a network of pieces of 
work will be performed by whom and which resources 
are exptoited for this work. i.e. a business process 
describes how an enterprise wit! achieve its Ixjsiness 
goals. The indivkJual pieces of work might be distributed 
across a multitude of different computer systems con- 
nected by some type of netwwork. 

The process of designing, developing and manu- 
facturing a new product and the process of changing or 
adapting an existing product presents many challenges 
to product managers and engineers to bring the product 
to market for the least cost and within schedule while 
maintaining or even increasing product quality. Many 
companies are realizing that the conventional product 
design process is not satisfactory to meet these needs. 
They require early involvement of manufacturing engi- 
neering, cost engineering, logistic planning, procure- 
ment, manufacturing, service and support with the 
design effort. Furthermore, they require planning and 
control of product data through design, release, and 
manufacturing. 

The correct and efficient executk>n of business 
processes within a company, e. g. development or pro- 
ductk>n processes, is of enormous importance for a 
corrpany and has significant Influence on company's 
overall success in the market place. Therefore, those 
processes have to be regarded similar as technology 
processes and have to be tested, optimized and moni- 
tored. The management of such processes is usually 
perfonned and supported by a computer based process 
or workf k>w management system. 

In a J. Spoon: ''Project Management Environ- 
ment". IBM Technical Disclosure Bulletin. Vd. 32. No. 
9A. Febmary 1990. pages 250 to 254. a process man- 
agement environment is described including an operat- 
ing environment, data elements, and application 
functions and processes. 

In R. T Marshak: "IBM's FlowMari^ Object-Ori- 
ented Vy/brkflow for Mission-Critical Applications". Work- 
group Conputing Report (USA). Vol. 17. No 5. 1994. 
page 3 to 13. the object character of IBM RowMark as 
a client/server product built on a true object model ttiat 



is targeted for mission-critical production process appfi- 
cation development and deployment is described. 

In H. A. Inniss and J. H. Sheridan: "Workflow Man- 
agement Based on an Object-Oriented Paradigm". IBM 
5 Technical Disclosure Bulletin, Vol. 37. No. 3. March 
1994. page 185. other aspects of object-oriented mod- 
elling on customization and changes are described. 

In F. Leymann and D. Roller: "Business Process 
Management with FlowMark". Digest of papers. Cat. 
10 No. 94CH3414-0, Spring COMPCON 94, 1994. pages 
230 to 234. the state-of-the-art computer process man- 
agement tool IBM FlowMari^ is described. The meta 
model of IBM FlowMark is presented as well as the 
implementation of IBM Flovirfy^ark. The possibilities of 
15 IBM Fk>wvMark for nxxJelling of business processes as 
well as their execution are discussed. The product IBM 
FlowMark is available for different computer platforms 
and documentation for IBM FlowMark is available in 
every IBM branch. 
20 In F Leymann: 'A meta nxxlel to support the mod- 
elling and execution of processes". Proceedings of the 
11th European Meeting on Cybernetics and System 
Research EMCR92. Vienna, Austria. April 21 to 24. 
1992. World Sdentffk: 1992. pages 287 to 294. a meta 
25 model for controlling business processes is presented 
>and discussed in detail. 

The "IBM RowMark for OS/2", document number 
GH 19-8215-01. IBM Corporation. 1994. available in 
every IBM sales offfoe. represents a typical modern, 
30 sophisticated, and powerful worMlow management sys- 
tem. It st^sports the modelling of business processes as 
a network of activities; refer for instance to "Modeling 
Workf tow", document nun*er SH 19-8241 . IBM Corpo- 
ratk)n. 1996. This network of activities, the process 
35 model, is constructed as a directed, acyclic, weighted, 
colored graph. The nodes of the graph represent the 
activities or workltems wtiich are performed. The 
edges of the graph, the control connectors, descrit^e 
the potential sequence of eo^cution of the activities. 
40 Def inttion of the process graph is via the IBM RowMark 
Definition Language (FDL) or the fc>uilt-in graphical edi- 
tor. The runtime conponent of the workflow manager 
interprets the process graph and distributes tiie execu- 
tion of activities to the right person at the right place, e. 
45 g. by assigrang tasks to a work list according to the 
respective person, wherein saki work list is stored as 
digital data witiiin saki workftow or process manage- 
ment connputer system. 

In F. Leymann and W. Altenhuber: "Managing busi- 
50 ness processes as an information resource". IBM Sys- 
tems Journal. Vol. 32(2). 1994. tiie mattiematical theory 
underlying the IBM FlowMark product is described. 

In D. BoHer: "Verifikation von V\forkflows in IBM 
Fk)wM£rk". in J. Becker und Q. Vossen (Hrsg.): 
55 "Geschaeftsprozessmodellierung und Workflows". 
International Thompson Publishing. 1995. the require- 
ment and possibility of the verification of workflows is 
descrit)ed. FurthernrK)re the feature of graphical anima- 
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tion for verification of the process logic is presented as 
it is implernented within the IBM FlowMark product. 

For implementing a computer based process man- 
agement system, firstly the txjsiness processes have to 
be analyzed and, as the resuJt of this analyas. a proc- 
ess nnodel has to be constructed as a network of activi- 
ties corresponcfing to the business process. In the IBM 
FIcwMark product, the process models are not trans- 
formed into an executable. At run time, an instance of 
the process is aeated from the process model, called a 
process instance. This process instance Is then inter* 
preted dynamically by the IBM FlowMark product 

The concept of events as such on the other hand is 
Known in the state of the art. Events for example play a 
role in database management systems. In database 
management systems event/trigger mechanism have 
been developed for consistency checking in databases 
as described for instance in A. M. Kbtz. Trigger mecha- 
nismen in Datenfcanksystenen, Springer Verlag, Berlin 
1989. Also events play a central role in the notion of 
active databases. In workflow systems, the semantics 
of an event is quite imprecise as applied by A. W. 
Scheer, Wirtschaftsinformatik. Springer Verlag. Berlin 
1 994 . where the event can be a termination condition of 
a previous activity or an external signal, such as the 
arrival of a letter or in general an incident occurring 
tndeperxlent from an activity informing an activity asyn- 
chroneousiy on some type of change. According to this 
prior art approach an event is restricted to a quite linrv 
ited spectrum of possible sources. The relationship 
between the activity and the event may be such ttet the 
activity requires that the event is signaled to it otherwise 
the activity will not continue beyond a certain point. It is 
also possftde tiiat an event signal^ to an activity will be 
perceived by ti^t activity and depending on that percep- 
tion might modify the activity's ongoing processing. An 
event might resuft from anywhere within a computer 
system or ev«i within networks of computer systems. 
Also the source of an event might be a hardware device, 
some software construct a human Interacting with a 
running computer system and so forth. 

11 .3 Ob|ective ol ttie Invention 

The invention is based on die objective to tightly 
integrate event mechanisnrs into workf kiw management 
systems. 

2 Sumvrairy and Aiilvantages of the Imfontion 

The objective of the invention is solved by claim 1. 
WFMS, encompassing one or more corrtputers, execute 
a multitude of process models consisting of a network of 
potentially distributed activities. For each activity infor- 
matk>n is defined within the WFMS which available pro- 
grams or processes do execute that activity. The cun-errt 
invention teaches to realize an event as an event activity 
encompassed by said process model sakJ event activity 



t>eing implemented as a special type of activity of saki 
WFMS and said event activity managing an event which 
may occur internal or external to the WFMS. 

The technique proposed by the current invention 

5 achieves a new level of integration between WFMS and 
event technology By exploiting and reusing the activity 
features very econonrtic implementations for events are 
achieved. In addition conceptual gaps between the con- 
cepts of activities such as program or process and 

10 events are completely avoided. Moreover the approach 
allows to handle tx)th, events occurring due to incidents 
within the WFMS as well as events having their source 
external to a WFMS. By conc^tually handling an event 
as any other activity (for instance as a process activity), 

IS this concqDt allows to treat really any type of incident 
within a computer system as an event The current 
approach thus supports the broadest possible spectrum 
of possible events. By reusing to a certain extertd the 
implementations of activities the overall system of a 

20 WFMS is not increased supporting compact and very 
responsive overall WFMS. 

Additional advantages of the invention are accom- 
plished by claim 2. 

According this teaching said event activities are imple- 
26 merits by inheriting features and capak^ilities of the 
class of activities or of a suk>-dass thereof according to 
the principles of object-orientation. 

Such an approach aUows for an elegant and very 
simple way of reusing capak)ilities already avaitatde 
so witNn a syst^n. 

Further acEditional advantages of the invention are 
aoconrplished by daim 3. 

Claim 3 teaches to inplement event activities by associ- 
ating with it an event generator being a program imple- 

35 menting said event According to the invention an event 
activity may have associate witii it an input container 
and/or an output-container, the event activity may be the 
source and/or target of one or more control-connectors 
and the event activity may be the source and/or target of 

40 one or more data-connectors. Moreover it is taught by 
tiie cunrent teaching, that the event activity may t>e 
associate with a notification mectianism allowing to 
freely define one or more actions to be performed by the 
WFMS if the event activity is not completed within a 

45 freely defined time period. 

This approach to events supports a complete trans- 
parency wheOier an event is of internal or external 
nature. Nevertheless the teaching allows to implement 
the event generator as a special purpose program 

so innplementing or handling really any type of event. Sep- 
arating the general aspects of an event, like signaling a 
dedk:at6d consumer that the event happen^, from the 
event generator avoids that these functions have to t>e 
realized over and over again. Instead these general 

55 aspects are implemented only orKe within tiie WFMS 
and are handled by tiie WFMS automatically Of course 
all features which are available to normal activities are 
made available to event activities too thus es^ing the 
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implementation of events significantly. For instance 
input and output containers allow to provide an event 
generator with run-time information or to make results of 
an event available to consumers of an event 

Further additional advantages of the inventbn are 
accomplished by claim 4. 

The invention suggest to introduce as one possible 
action which may be perfonmed by the notification 
mechanism to automatically terminate the event if the 
event is not corrpleted witNn a predefined time period. 

Such an approach allows to sinrKilate a successful 
termination of an event activity if required. 

Further additional advantages off the Invention are 
accomplished by claim 5 and 7. 
The current teaching allows that an event activity may 
be the source of one or more outgoing control connec- 
tors targeting at conresponding target activities. Such a 
process model will then make sure that the target activ- 
ities wW be informed automatically by the WFMS on the 
event once the evert is signaled to the waiting event 
activity an the event activity terminated. An outgoing 
control connector optranally may be associated with a 
logical predicate as outgoing transition condition mode- 
ling the fact that a target activity will be activated if said 
event activity terminated and said outgoing transition 
condition evaluates to true. The current invention fur- 
thermore teaches that one or more incoming control 
connectors of the corresponding source activities may 
targeting at an event activity. Such a process model will 
then allow the WFMS to automatically start the event 
activity once a source activity terminated its processing. 
An incoming control connector optionally may be asso- 
ciated with a logical predicate as incoming transition 
condition modeling the fact that the event activity will be 
started only by the WFMS if m addi^ said incoming 
transition condition evaluates to true. 

By this approach already tiie process graph altews 
to define via the control connectors which other activi- 
ties are to be started after an event or which process 
activities automatically start an event activity. This tech- 
nique establishes a standard approach to inform poten- 
tial consumers on an event and to start an event activity 
and event generators. Thus tiie event activities, the 
event generators or the potential consumers are 
reieved from performing extra activities for tiiat pur- 
pose. Moreover event generators and event activities 
with interest in a certain event (either in creating or in 
waiting on an event) become significant easier to imple- 
ment. In addition above mentioned handling of the 
events is done automatically by the WFMS. The current 
invention does not restrict these source and target activ- 
ities to a specific type of WFMS activities. Therefore the 
source and/or target activities migtit represent standard 
process activities, program activities or otiier types of 
activities but according to the current Invention rt 
be also possible tiiat one or both of them represent also 
event activities. In other words the curent invention also 
supports chains or even complex graphs of event activ- 



ities. 

Further additional advantages of tiie invention are 
accomplished by daim 6. 

Accort£ng claim 6 ttie WFMS is activating an event 
5 activity automatically virtien instantiating a process 
model if said event activity is not a target of a control 
connector. 

Thus no extra implementation is required to start a 
certain event generator. The WFMS takes care about 
10 these aspects automatically 

Further additional advantages of the invention are 
accomplished by daim 8. 

According to daim 8 tine WFMS registers said event 
activity as awaiting consumer of said event once said 
15 event activity is activated by the WFMS and wherein fur- 
ttier said WFMS registers said event as posted event 
once tiie occunence of said event is signaled t>y said 
event generator. 

Due to tills teaching again tine implementation of an 
20 event activity becomes much easier as the interest in a 
certain event is automatically detected by the WFMS kiy 
reading the process graph and the WFMS takes over 
responsibility to register an event activity's interest in 
that event. Moreover tiie implementation o* event gener- 
is ators is also significantly simplified as an event signaled 
tjy an event generator Is registered automatically by tiie 
WFMS as posted event. 

Further additional advantages of the invention are 
acconplished by daim 9. 
30 This teaching suggests tiiat a target activity is activated 
by said WFMS if as a f irst condition the event activity 
terminated and if as a second condition the outgoing 
transition condition evaluates to true independent at 
vi*iich point in time and in which sequence said first and 
35 said second condition are fulfilled. 

This behavior characteristic avoids that the sig- 
naled event is "consumed" if tiie transition condition is 
not fulfilled exactly at the point in time tiie event 
occurred. 

40 Further additional advantages of tiie invention are 
accomplished by daim 10. 

Claim 10 suggest to extend the WFMS navigator, per- 
forming navigation of operation trough tiie process 
graph of a process-model, by an event management 
45 system extending and inter-operating with said WFMS 
navigator. The event management system encom- 
passes the component of an event monitor administer- 
ing awaited events in at least one awaited event tak)le 
and further administering signaled events in at least one 
so posted event table. An evert generator is signaling tiie 
occurrence of said evert to said event monitor. 

This teaching extends ttie navigator witii additional 
features to administer on one side all events which have 
been signaled to and to handle on tiie other side all 
55 potential consumers of an evert and to associate both 
sides. Neither event generatas nor activities do have to 
take care of these aspects. 

Further additional advantages of ttie invention are 
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accomplished by claim 1 1 . 

The teaching of daim 1 1 suggests an event n^nage- 
ment system encompassing the component of an event 
manager maintaining irrformation on the events allowing 
to verify con-ectness of an event if said event is being 
signaled. 

Such an access further Increases the reliability of 
the overall system. 

Further additional advantages of the invention are 
accomplished by claim 12. 

According to claim 1 1 the WFMS sends, if It detects that 
an event activity is awaiting for an event, an awaited 
event notification to said everrt monitor and if then said 
event monitor detects a matching posted event indica- 
tion in said posted event table saki event monitor indi- 
cates said event together with event data to said WFMS. 
If otherwise no matching posted event notification is 
detected sard event monitor stores an awaited event 
irKlication in said awaited event table. Also according to 
claim 12 said event generator indicates the occurrence 
of an event by a posted event indication to said event 
monitor which verifies said posted event indication by 
consulting said event manager and then stores said 
post^ event indication in said posted event table and if 
then said event monitor detects a matching awaiting 
event irKlication in said awaiting event table it indicates 
this together with event data to the WFMS. 

The approach of daim 12 improves responsiveness 
of the WFMS by at once checking whenever eith^ a 
new event anived or a new consumer is waiting for an 
event whether a matctiing event-oonsumer pair can be 
detected allowing the WFMS to inform ttiat consumer 
on the signaled everrt. 

Furtiier additional advantages of the invention are 
accomplished by claim 13. 

Claim 13 teaches that an event generator is informed, if 
an awaited event indication is stored in said awaits 
event table, on tills awaits event indication. 

This technique informs an event generator auto- 
matically on consumers awaiting soma kind of event. 
Such an approach avoids that an event generator peri- 
odically has to check fbr possible event consumers araJ 
thus avoids performance degradations. 

3 BrBef Description off lUh® Drawings 

Figure 1 is a diagram-reflecting multq>le aspects of 

tiie embedding of events as a new type of 

activity within a WFMS 
Rgure 2 is a visusdization of the two fundamental 

embedding modes of events as event 

activities within a process model 
FiguireS reflects the major components of the 

Event Management System 
Rgure 4 depicts the structi^e of tiie "awaited event 

table" and tine "posted event table" 
Rgure 5 is a visialization of the FDL registration 

definitions required to model an event 



Figure 6 is a visualization of tiie FDL defiration of 
an event 

Rgure 7 is a visualization of the FDL definition fbr 
exploiting the notification mechanism for 
5 an event 

Rgure 8 is a simple sample process model reflect- 
ing the usage of event activities 

Rgure 9 reflects the most important data struc- 
tures of the example of Figure 8 
10 Rgure 10 is a visualization of an event modeled as 
an event activity within the process model 
of the example of Rgure 8 

4 Description of the Preferred Emltodinnent 

IS 

The cuaent invention is illustrated fc)as^ on IBM's 
FlowMarIc workflow management system. Of course 
any other WFMS could be used instead. Furthernnore 
the current teaching applies also to any other type of 
20 system which offers WFMS functionalities not as a sep- 
arate WFMS but within some other type of system. 

4.1 Bntroduction 

25 The following is a short outline on the basic con- 
cepts of a workflow managem&it system t>ased on 
IBM^s FlowMarkWFMS: 

From an enterprise point of view the management 
of business processes is becoming increasingly impor- 

30 tant: business processes or pirocess for short control 
which pece of work will be performed by whom and 
which resources are exploitai fbr tfus work. i.e. a busi- 
ness process descrt>es ftow an enterprise will achieve 
its business goals. A WFMS may support tx>th, tiie 

35 modeling of tojstness processes and their execution. 

Modeling of a business process as a syntactical 
unit in a way tiiat is directly supported by a software sys- 
tem is extremely desirable. Moreover, the software sys- 
tem can also work as an interpreter t>asically getting as 

40 input such a model: The ntodel. call^ a process 
ntodei or mrtdCo%:r motEeO. can then be instantiate 
and the Individual sequence of work steps depending 
on the contert d ttie instantiation of ttie model can t>e 
determined. Such a model of a business process can be 

45 perceived as a template for a class of similar processes 
performed wittiin an enterprise: it is a schema describ- 
ing all possible execution variants of a particular kind of 
tsusiness process. An instance of such a model and its 
interpretation r^^ents an irvlivtdual process, i.e. a 

so concrete, context deperxient execution of a variant pre- 
scribed by the model. A WFMSs facilitates the manage- 
ment of business processes. It provides a means to 
descrlb>e models of business processes (buiki time) and 
it drives business processes based on an associated 

55 fXKxM (run time). The meta model of IBM s WFMS 
FkywMarK i.e. the syntactical elements provided for 
descrasing business process models, and the meaning 
and interpretation of these syntactical elements, is 
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described next. 

A process model is a complete representation of a 
process, conprlsing a process cfiagram and the settings 
that define the logic k>ehind the components of the dia- 
gram. Using various sendees provided by Flowf^ark 
these biildtime definrtions the process models are then 
converted into process templates for use by FlowMark 
at runtime. Important components of a RowMark proc- 
ess nrKxIel are: 

■ Processes 

■ Activities 

■ Blocks 

■ Control Flows 

■ Connectors 

■ Data Containers 

■ Data Structures 

■ Conditions 

■ Programs 

■ Staff 

hfot all of these elements will t>e described below. 

On this bad^ound a process, modeled by a proc- 
ess model within FlowMark. is a sequence of acfivrties 
that must be completed to accomplish a task. The proc- 
ess is the top-level element of a RowMari^ workflow 
model. In a FlowMart^ process, it can be defined: 

• How work is to progress from one activity to the 
next 

• Which persons are to perfomi activities and what 
programs they are to use 

• NWhether any other processes, called subpvoc- 
esses. are nested in the process 

Of course multiple instances of a FkDwMark process can 
run in parallel. 

Activities are the fundamental elements off the 
meta model. An activity represents a business actkm 
that is from a certain perspective a semantical entity of 
its own. With the model of the business process it might 
have a f ine-slructure that is then represerrted In turn via 
a model, or the details of it are not of interest at all from 
a kxisiness process modeling point of view. Refinement 
of activities via process models altows for both, mode- 
ling business processes bottom-up and top-down. 
Activities being a step within a process represents a 
piece of work that the assigned person can complete by 
starting a program or another process. In a process 
model, the following information is associated with each 
activity: 

• What conditions must be met before the activity can 
start 

• Whether the activity nrust be started manually by a 
user or can start automatically 

• What condition indk:ates that the activity is com- 
plete 



Whether control can exit from the activity automati- 
cally or the activity must first be confirmed as com- 
plete try a user 

• How much time is aBowed for connpletion of the 
5 activity 

• Who is responsible for completing the activity 
Which program or process is used to complete the 
activity 

What data is required as input to the activity and as 
10 output from it 

A FlowMark process model consists of the fbllGwing 
types of activities: 

IS l>iogram activity: Has a program assigned to per- 
form It The program is invoked v»fhen the activity is 
started. In a fully automated workftow. tfie program 
performs the activity without human intervention. 
Otherwise, the user must start the activity by select- 
ing it from a runtime work list Output from tiie pro- 
gram can be used in the exit condition for the 
program activity and for the transition conditions to 
other activities. 

Process activity: Has a (sub-)process assigned to 
perform it. The process is invoked when the activity 
^ is started. A process activity represents a way to 
reuse a set of activities that are common to different 
processes. Output from the process, can be used In 
tiie exit condition for the process activity arxl for tiie 
transition conditions to ottier activities. 

The flow of control, i.e. tiie controi f tow through a 
running process determines the sequence in which 
activities are executed. The RowMark workflow man- 
ager navigates a path through the process that is deter- 
mined by the evaluatfon to tme off start conditions, exit 
conditfons. and transition conditions. 

The results that are in general produced by the 
work represented t)y an activity Is put into an output 
container, which is associated vwth each activity. Since 
an activity will in general require to access output con- 
tainers of other activities, each activity is associated in 
addition witti an input container too. At run time, tiie 
actual values for the formal parameters IsuikHng the 
input container of an activity represent the actual con- 
text of an instance of the activity. Each data container is 
defined by a data structure. A data structure is an 
ordered list of variables, called members, that have a 
name and a data type. Data connectors represent the 
transfer of data from output containers to input contain- 
ers. When a data connector joins an output container 
witii an input container, and the data structures of tiie 
two containers match exactiy. ttie FlowMark workftow 
manager maps the data automattoally. 
55 Connectors link activities in a process model. 
Using connectors, one defines tiie sequence of activi- 
ties and the fransmission of data between activities. 
Since activities might not be executed arbitrarily tiiey 
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are bound together via control connectors. A control 
connector might be perceived as a directed edge 
between two activities; the activity at the connector's 
end point cannot start before the activity at the start 
point of the connector has finished (successfully). Con- 
trol connectors model thus the potential flow of control 
within a business process model. Defdull connectors 
specify where control should flow when the transition 
condition of no other control connector leaving an activ- 
ity evaluates to true. Default connectors enable the 
workflow model to cope with exceptional events. Data 
connector specify the flew of data in a workflow nwdel. 
A data connector originates from an activity or a block, 
and has an activity or a bkxk as its target. One can 
specify that output data is to go to one target or to mul- 
tiple targets. A target can have more than one incoming 
data connector. 

Cond'rttons are the means by wrtiich it is possBDle to 
specify the flow of control in a process. In RowMark 
process nxxJels fogk^al e)^essions can be defined that 
are evaluated by RowMark at runtime to determine 
when an activity may start end. and pass control to the 
next activity. Start condlttons are conditkxis that deter- 
mine when an activity with incoming control connectors 
can start. Tlie start conditfon may specify that all incom- 
ing control connectors must evaluate to true, or it may 
specify that at least one of them must evaluate to true. 
Whatever the start condition, all incoming connectors 
must be evaluated before the activity can start. If an 
activity has no incoming control connectors, it becomes 
ready when the process or block contairang it starts. In 
addition, a Boolean expression called transition condl- 
tk>n is associated with each control connector. Parame- 
ters from output containers of activities having already 
produced their results are fonowed as parameters refer- 
enced in transitk>n conditions. \Nhen at run time an 
activity terminates successfully all control connectors 
leaving tNs activity are determined and the truth value 
of the associated transition conditions is computed 
t>ased on the actual values of their parameters. Only the 
end points of control connectors the transition condi- 
tions of which evaluated to TRUE are conskJered as 
activities that n^ght be executed l3ased on the actual 
context of the business process. Transition conditions 
model thus the context dependent actual fkaw of control 
within a business process 0-e. an instance of a model). 
Business processes erKX)mpass long running activities 
in general; such an activity need to be allowed to 
become intenupted. Thus, terminatkxi of an activity 
does not necessarily indicate that the associated task 
has been finished successfully In order to allow the 
measurement of successfullness of the work performed 
by an activity a Boolean expression called exit condi- 
tkHi is associated with each activity. Exactly the activi- 
ties the exit conditk>n of which evaluated to true in the 
actual context are treated as successfully terminated. 
For determination of the actual control flow precisely the 
successfully terminated activities are conskiered. Thus 



the logical expressbn of an exit condition, if specified, 
must evaluate to true for control to pass from an activity 
orbk)ck. 

Beside describing the potential flow of control and 
5 data between activities a business process model also 
encompasses the description of the flow of the activities 
itself kDetween "resources" actually performing the 
pieces of work represented by each activity. A resource 
may be specified as a particular progrm, person, a 

10 role, or an organizational unit. At run time tasks are 
resolved into requests to particular persons to perform 
particular activities resulting in workitems for that per- 
son. Staff assignments are the means to distrikxite 
activities to the right people in the sequence prescriksed 

15 by the control f tow aspect of a business process model. 
Each activity in a process is assigned to one or more 
staff members defined in the RowMark database. 
Whether an activity is started manually by the user or 
automatically by the Rowf^ark workflow manager, and 

20 whether it reqiires user interactfon to complete or com- 
pletes automatically, a staff memt>er must be assigned 
to it. RowMark staff definition entails more than dentify- 
ing people at your enterprise to the RowMark clatat>ase. 
For each person defined, you can specify a levd. an 

25 organization, and muHiple roles. These attrilxjtes can 
k>e used at run time to dynamically assicpi activities to 
people with suitak)le attributes. 

In the RowMark workflow manager, program 
means a corrputer-based applicatfon program that sup- 
so ports the work to t>e done in an activity. Program activi- 
ties reference executat^ie programs using the logical 
names associated with the programs in RowMark pro- 
gram registrations. The program registration can con- 
tain run-time parameters for the executable program. 

35 Rowf^rk consists, at the coarsest level, of a buikJ 
time component and a run time component The buikJ 
time component supports the nrxxieling of business 
processes according to the meta model described 
above arxl the run time component supports the corre- 

40 spending semantics. Both components are imple- 
mented in a client/server structure The client delivers 
the interaction with the user via an cbject-oriented 
graphical interface, invokes kx^l tods, arxJ provkies 
animation. The server maintains the database tor proc- 

45 ess instances, navigates through the process graph, 
and assigns the activities to the proper resources. 

Process delinitkMi includes modeling of activities, 
control connectors t>etween the activities, input/output 
container. arxJ data connectors. A process is repre- 

50 sented as a directed acydU: graph with tiie activities as 
nodes and the control/data connectors as the edges of 
the graph. The graph is manipulated via at>uilt-in, event- 
driven. CUA compliant graphic editor. The data contain- 
ers are specified as named data structures. These data 

55 structures themselves are specified via the DataStruc- 
tureDefinition fadlity. FlowMark distinguishes tiiree 
main types of activities: program activities, process 
activities, and bkxks. Program activities are imple- 
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merited through programs. The programs are registered 
via the Program Definition facility. Blocks contain the 
same constructs as processes, such as activities, con- 
trol connectors etc. They are however not named and 
have their own exit condition. If the exit condrtion is not 5 
met. the block is started again. The Ijlock thus imple- 
ments a Do Until construct. Process activities are imple- 
mented as processes. These subprocesses are deJined 
separately as regular, named processes with all its 
usual properties. Process activities offer great flexibility t 
Ibr process definition. It not only allows to construct a 
process through permanent refinement of activities into 
program and process activities (top-down), but also to 
build a process out of a set of existing processes (bot- 
tom-up). In particular, process activities help to organize t 
the modeling work if several process modeler are work- 
ing together. It alk3ws the team merrteers to work inde- 
pendently on different activrties. Program and process 
activities can be associated with a time limit The time 
limit specifies how long the activity may take. If the time 1 
is exceeded, a designated person is notif ied. If this per- 
son does not read within another time limit the process 
administrator is notified. It not only helps to recognize 
critical situation but also to detect process delfciencies 
as all notifffcations are recorded in an audit trail. 

All data structures used as templates for the con- 
tainers of activities and processes are defined via the 
Data Stnjcture Definitk)n Facility. Data Structures are 
names and are defined in terms of elementary data 
types, such as f toal, integer, or string and references to 
existing data structures. Managing data structures as 
separate entities has the advantage that all interlaces of 
activities and their implementations are managed con- 
sistently in one place (similar to header files in progranv 
ming languages). 

All programs which implement program activities 
are defined via the Program Registration Facility. Regis- 
tered for each program is the name of the program, its 
location, and the invocation string. The invocation string 
consists of the program name and the command string 
passed to the program. 

Before process instances can be created, the proc- 
ess model must be translated to ensure the correctness 
and completeness of the process nrKxiel. The translated 
version off the model is used as a template when a proc- 
ess instance is created. This altows to make changes to 
the process model without affecting executing process 
Instances. A process instance is started either via the 
grapNcal interface of via the callable process applica- 
tion programming interface. When a process is started, 
the start activities are kx»ted. the proper people are 
determined, and the activities are posted onto the work 
list of the selected people. If a user selects the activity, 
the activity is executed and renrwved from the work list 
of any other user to whom the activity has been posted. 
After an activity has executed, its exit condition is evalu- 
ated. If not met, tiie activity is rescheduled for execution, 
otherwise all outgoing control connectors and the asso- 



ciated tiansitton conditions are evaluated. A control con- 
nector is selected, if the condition evaluates to TRUE. 
The target activrties of the selected control connectors 
are then evaluated. If tiieir start conditions are true, they 
are posted to the work list of selected people. A process 
is considered terminated, if all end activities have com- 
pleted. To make sure that all end activities finish, a 
death path analysis is performed. It removes all edges 
in the process graph which can never be reached due to 
0 failing transition conditions. All information about the 
current state of a process is stored in the database 
maintained by tiie server. This allcws for forward recov- 
ery in tiie case of crashes. 

5 4.2 Concepts 

To achieve an integration of events within \NFfsAS 
which is as seamless as possilDle tiie basic approach of 
the cunrent invention is to let events appear as a certain 
?o type of activity in terms of a WFMS. More precisely this 
patent application teaches how ei/ents can be treated 
and implemerTted as a subclass of the class of activities 
inheriting (in tiie sense of object orientation) the com- 
mon properties of activities. 
25 nowMark activities are either program activities or 
process activities. Program activities are implemented 
via a program which is invoked when tiie activity is exe- 
cuted; process activities are implemented via a sub- 
process, which is started when the activity is executed. 
30 The sequence of execution of the various activities of a 
process model are described via the control connectors. 
Activities which are only the target of control connectors 
are called end activities, activities which are only the 
source of control connectors, are called start activities. 
35 Which control connector is being followed is defined via 
predicates. Each activity is associated with an input 
container and an output container. The input container 
contains the data required by the Implementation of the 
activity to perform the correct processing; the output 
40 container is filled by the activity with information to con- 
trol the process and data to be used by sut»sequent 
activities. Data connectors are used to describe what 
data from which output container should be used for the 
data in the input container of activities subsequent 
45 according to the process graph. Activities are associ- 
ated with a notification mechanism, which allows to 
specify that an action, such as sending a notification 
message to a designated user, is performed, if the activ- 
ity has not been worked on for a defined period of time. 
so The concept of events is tiie mecfianism which 
altows the process modeler to specify that tiie process 
shoiikl wait at this point until the specified event hap- 
pens. This event could be that a certain date occurs, or 
tiiat a letter shoukJ be received from a customer. The 
55 occunrence of the event may t>e signalled from an activ- 
ity within anotiier process or from any other program, 
such as an agent in Lotus Notes. In general an event is 
an incident occurring independent from an activity 
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informing an activity asynchroneously on some type of 
change. This change might be internal or external to the 
WFMS. The relationship between the activity and the 
event may be such that the activity requires that the 
event is signaled to it othenwise the activity will not con- 5 
tinue beyond a certain point. It is also possible that an 
event signaled to an activity will be perceived by that 
activity and depending on that perception might modify 
the activity's ongoing processing. An event might result 
from anywhere within a computer system or even within w 
networks of computer systems. Also the source of an 
event might be a hardware device, some software con- 
struct, a human interacting with a running conputer 
system arxj so forth. 

The patent application shows how events can be 
modelled within a WFMS as a special kind of activity, 
the event activity. It specializes in the sense of object 
orient technology the general activity and inherits all 
properties of the general activity Therefore, an event 
(activity) may be associated with an input and output 
container and niay k>e the source arxi the target of con- 
trol connectors as well tiie source and target of data 
connectors; i.e. all constructs and techniques available 
to general activities are available to event activities 
according to the current teaching too. Events may have 
a start condition arxJ may be associated with a notifica- 
tion. An event activity is associated with an event similar 
to process activities which are associated witii pro- 
grams. 

Thus an "event" descrit>es a conceptual and 
semantical entity, while tiie "event activity" is the nxxlel 
of that event modelled with tiie features of a WFMS. The 
programs associated with tiie event are called event 
generators and represent the means and constructs for 
creating or handling a particular event 

Figure 1 reflects multiple aspects of ttie embedding 
of events as a new type of activity witiiin a WFMS 
according the teaching of tiie cunent Invention. The new 
type of activity, tiie event activity 100. is realized as a 
sub-class of the class of activities 101. Via relationship 
and inheritance mechanisms the full spectrum of fea- 
tures and capatxlities available to activities is made 
available to event activities too. Thus event activities 
may exploit the available notif cation features 102. the 
full spectrum of data structure features 103 or tiie vari- 
ous connector features like control cormedors 104 arxl 
data connectors 105. Also shown by Figure 1 is the rela- 
tionship of tiie nrxxlel of an event 106 with one or nfK>re 
event activities 100 and the relationship of a program 
107. an event generator implementing or harxlling an 
event, with one or more everrt activities 106. 

The control cormedors originating from an event 
activity are treated as usual, i.e. their truth value of pred- 
icates potentially associated with those control connec- 
tors contribute to starting conditions of activities. Also, 
there may be more than one control connector emanat- 
ing from a particular event activity. The usual navigation 
semantics will evaluate the transition conditions of the 



associated conti-ol connectors immediately; thus, 
events will not be physically consumed (in the sense 
that an event can t>e dedicated to a particular control 
connector leaving the event activity node) but are avail- 
able for all originating branches. If exclusive validity of 
an event for a particular branch is required it must be 
expressed via suitable transition conditions. 

An event activity can also be a target of a control 
connector. This means that an instance of the corre- 
sponding event is aeated (t>ut not signalled) if the tran- 
sition condition of the control connector pointing to the 
event activity is fulfilled. Using control connectors point- 
ing to event activities can be used to explk:itiy activate 
events wittiin particular process instance contexts. If an 
event is activated, the activity waiting for ttiat event has 
registered for that event and all other activities being 
according to tiie FkiwMark process model the target of 
a control connector originating at the event activity are 
then potential consumers of that event 

Figure 2 illustrates how two different cases for 
eni>edding events as event activities within a process 
model can be differentiated, exactiy as is the case with 
regular activities. On the left side (1), tiie activity A 201 
must have terminated successfully and the transition 
25 condition 202 between A and the event activity E 203 
" must have been evaluated to true' before the event 
node E is sensitive for recognition. Thus, if an instance 
of E is signalled, this is not recognized before tiie transi- 
tion concfition between A and E is met Once E is sensi- 
30 tive for recognition (t e. activated) the activity B 204 has 
registered for tiie appropriate instance of E automati- 
cally ttirough tiie nrxxJelled process cp-aph. Event activi- 
ties for this first type may be used for instance if the 
cause of an event is located at least partially within a 
35 process model itself. 

On tiie right side (2). the transition condition 210 
between tiie event activity E 21 1 and tiie activity B 212 
will be evaluated as soon as tiie event E is recognized 
even if the activity A 213 has not been terminated. Con- 
40 sequentiy. E is activated when the process model is 
Instantiated, i.e. B has registered for E right away. 

When activating an event activity its associated 
input container is materiafized. The usual rdes for data 
connectors do apply The output container of an event 
45 activity is created by the event generator associated 
with tiie subject event (see below). 

4.3 Componems of Event Management Services 

50 The navigator is the piece of tiie workflow manage- 
ment system ttiat performs the navigation through the 
process graph. For handling events tiiis navigator is 
extended by an Event Management System encom- 
passing event management services which are inter- 
55 operating witti the navigator. These event management 
services are logically different components which may 
or may not coincide witii physical means implementing 
tiiose functions. Figure 3 reflects tiie major components 
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of the event management sennces. The event monitor 
301 is responsible tor keeping track of awaited and 
posted events. TTie event generators 302 are pro- 
grams that signal the occurrence of an event to the 
event monitor. The event manager 303 keeps the infor- 
mation about events. 

When the navigator 304 detects that an event is 
expected by particular activities of a process instance 
this is indicated to the event monitor. If the event monitor 
finds a matching entry in its posted event table 305 it 
indicates so immediately to the navigator and passes 
the associated data its response. Othennnse, the 
event monitor reflects the awaited event by an appropri- 
ate entry in the awaited event table 306. 

An event generator signals the occurrence of an 
event to the event monitor. The event monitor verifies 
the conrectness of the event by consulting the event 
manager. If the event monitor detects a conresponding 
entry in the "awaited event table" this is indicated to the 
navigator. Otherwise, the event is inserted into the 
"posted event table". 

The tables "awaited event table" and "posted event 
table" are first of all logical objects. Physically they actu- 
ally may be implemented as different or as common 
tables. 

4 A Tracking of Events 

It can be perceived that events and their event indi- 
cations within the posted and awaited event table are 
managed in tabular formats as depk:ted in the Figure 4. 
ProcID refers to the identifier of the process instance in 
whrch the event is waited for. The EventID identifies a 
particular event in this process instance (as node in the 
process nrKXiel). The EventName refers to the category 
of the evem and the InputContainer column contains the 
actual values of the fields in the associated input con- 
tainer of the event 

It has to t>e noted that the EventID is needed 
because events having an incoming control connectors 
are only "activated" If the transitk>n conditions of the 
incoming control connectors are met and the start con- 
dition is true. An event whk:h is not activated is not 
reflected in the "awaited event table". Events with no 
incoming control oonneckor are activated at process 
instantiation time. 

The posted events table is used to store generated 
events which are currently not waited for as no potential 
consumer has registered for it. Such an event is kept in 
this table until somebody registers for it (potentially, an 
event may be kept "forever") or if it is renwved via gar- 
bage collection. The ProcID column in this table repre- 
sents an optional value for tupels of this table and can 
be used for specifying particular process instances 
whk:h might consume the event instance. 



4.5 Cancelling Events 

An awaited event can be cancelled in two ways : (1) 
as the result of a notification action, such as FORCE 

5 TERMINATE or (2) through an explicit request from the 
user via functfons supplied by the event monitor. When 
an awaited event is cancelled, it is removed from the 
waited event table and the event monitor signals the 
completion of the event to the navigator. Any outgoing 

10 control connector is treated as if the event had hap- 
pened normally. 

4.6 Event Identification 

15 The association of an incoming event, such as 
receiving a letter, with the waited for event is performed 
by comparing the kJerrtiflcation fiekJs provided by the 
event generator with the f iekJs defined in the input con- 
tainer plus the fields defined in the input container by 

20 default which is the process Instance identification and 
the event tdentificatk>n. No problem arises H the event 
generator itself provides the process Instance kientif k:a- 
tk>n arc the event klentification. If the process instance 
kientif ler not supplied, the f iekJs in the input contai^-^r 

2^ are cor-p^ ed with the appr>.x3>riate fields delivered 
^e eve rt generator (signature matching). 

4.7 Event Generator 

30 The event generator signals ttiat an event has hap- 
pened by calling the event monitor via the event nrx>nitor 
interface. The event generator can determine when the 
event should be signalled. This can be done by periodi- 
cally querying the event monitor to determine if a new 

35 entry for the event generator has t>een entered in the 
awaited event table. An event generator may also regis- 
ter itself with the event nronitor and request tfiat each 
new registration of an awaited event is signalled to the 
event generator. 

40 The supplied date/time event generator for example has 
a data structure with a date f lekJ arxi a time field. These 
fields can either be filled by a data connector leading to 
that event or values set as defaults by the process mod- 
eler. The time^te event generator has registered with 

45 the event monitor that it should be called when a new 
event is registered. 

4^ Event ntonitor Programming interface 

50 The event nrK)nitor provkles an applk^ation program- 
ming interface to allow applications to request event 
nK>nitor functfons. The set of functions include requests, 
such as querying the posted event table, removing 
entries from the posted event table, querying the 

55 awaited event table, removing entries from the awaited 
event table, and inserting entries into the posted event 
table. 
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4.9 Event Registration 

An event activity is always assodated with an 
event. The event has a number of properties: the name 
of the program implementing the event generator, the 5 
name of the e/errt. and an indicator whether the event 
generator should be sterted as part of starting the Flow- 
Marl^ server. An important property is the operation 
mode of the event generator, which defines whether the 
event generator should be called every time a new event w 
is added to the awaHed events table or not If specified, 
this allows the event generator to keep internal tables 
for efficient processing and does not require periodically 
reading the awaited event tak)le. 

IS 

4.10 Event Notification 

Events €ilso inherit (in the sense of object oriented 
techrK>logy) the notion of notification from the activity. 
rJotification allows to define actions which are taken so 
whenever the defined time lor completion is exceeded. 
Extensions to the notification mechanism allow to spec- 
ify other actions than just sending a notification mes- 
sage to a designated person. These extensions include 
actions like t^minating the activity. 

4.1 1 Process; Model Additions 

The support of events requires minor alditions to 
the Fk>wMark Defbution Language (FDL). 30 
Events are registered On the sense of the FDL) via the 
EVENT section. It is similar to the PROGRAM sectk>n 
which supports the registration of programs. Figure 5 
shows the FDL registration of the event "Walt for Cus- 
tonner Response". The associated generator program 3s 
is "MailCheckProgram*. The program is started as a 
result of starting the FtowMark server, specified due to 
AUTOSTART, and is notified whenever an event is 
entered into the awaited event tat>te, specified due to 
NOTIFY ^ 

Event activities of a process nxxlel are defined via 
the EVENT_ACTlVITf section. This mechanism is 
almost klentfeal to the PROGRAM_AGTlVlTY keyword. 
The event tfpe is specified via the EVENT_TYPE key- 
word followed by a string containing the event type. A 4s 
particular event type may be specified only once within 
a process nrxxJel. Figure 6 shows how an event is 
defined. The data structure "Event WentHfcation'' 
defines the structure of the input container assodated 
with the event K contains all relevant infbrnnatk>n to so 
identify the event. This information is used by the everrt 
monitor to compare it with the information supplied by 
the event generata. The data structure "Response 
Infbrmation'* defines the structure of the output con- 
tainer associated with the event. The data is supplied t)y ss 
the event generator. 

Notification of events is enhanced to provide the 
capability to force terminate the event, that means that 



the event is considered complete even if no event has 
been signalled during the specified time. Figure 7 
shows how it could be specified that it shouki only be 
waited 1 4 days for the customer letter to arrive. 

4.12 Advantages 

The proposed method of treating events as activi- 
ties has, besMes the effect of offering a seamless exten- 
sion and transition of workflow activities, a number of 
advantages over other possitsle approaches that treat 
events differently. 

1 Events follow the same metaphor as activities. 

1.1 Control Connectors activate an event. 
The predicates on the incoming control corv 
nectors as well as the outgoing control connec- 
tors allow to specify which event shouki l>e 
waited for and which activity shoukl be exe- 
cuted as the result of the happening of an 
event. Events without an incoming control con- 
nector are immediately activated as are start 
activities. 

1 .2 Data Connectors alk>w to f ill tiie input con- 
tainer with the event relevant data. No new 
mechanism is required to identify the instarKO 
of the event for which it shouki be waited for. 

1.3 Input Containers identify to activities what 
the context is in which tiiey are called. The 
same is true for event activities as the contents 
of the input container kSentifies the partkxdar 
characteristics of the event whk;h is waited for. 

1.4 Output Containers contains the process 
relevant information generated by an activity. 
For event activities, the event signaller provides 
this information, for example, tfie klentiffcation 
of the letter which has been received, wivch is 
process relevant information. 

1.5 NcMification alkjws to specify what shoukJ 
happen if an activity tias not t>een completed 
within a defined time timlt. The same betavior 
is true for event activities, where this mecha- 
nism is used in the same way. 

1.6 Events can be handled within Spheres of 
Joint Compensation the same way as activi- 
ties. 

2 Events can be graphically managed the same 
way as are activities. 

3 Events can be described in the FlowMark Defini- 
tion Language with similar constructs as program 
activities. 

4 Treating events as activities allows to re-use the 
code used for processing process nrxxjels. such as 
navigating the graph. Re-use of this code Provides 
a nunnber of advantages, such as 
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4.1 Less errors 

4.2 Easier testing 

5 Events can be monitored the same way as otfier 
activities via the process instance-monitor. 

All in ail these advantages help to conpactify the 
overall system, contribute to minimize the implementa- 
tion effort and thus increase the responsiveness of the 
WFMS. 

4.13 Example 

A sinrple process model in Rgure 8 illustrates the 
usage of events. In a claims processing application of 
this example additional info is required from a customer 
801 . The process waits until information is received 802. 
If the customer responded via fax, the fax is processed 
with a certain piece of software 803, otheoMrise another 
piece of software is used 804. 

Figure 9 shows the definitions of the nxjst important 
data structures being off inrportance within the example 
of Figure 8. Finally Figure 10 is a visualization of the 
event modeled as an event activity "^It for 
Response" in lines 5 to 9 within the process model of 
the example of Figure 8. Figure 10 further demonstrates 
in lines 14 to 21 usage of control connectors and in line 
21 to 31 usage of data connectors for the event activity. 

5 Acronyms 

DB Database 

FDL FlowMark Definition Language 
WFMS Workflow Management System 

Claims 

1. A computer system encompassing one or nrx>re 
computers storing an Implementation of a process- 
model for a workflow-process-environment said 
process-nfxxlel managed and executed by said 
computer system, said computer system t>eing 
characterized by 

at least one event-activity encompassed by 
sakJ processrmodel saki event-activity being 
implemented as an activity off sakJ workflow- 
process-environment 
arxJ 

saki event-activity managing an event occur- 
ring internal or extemal to the worWtow-proc- 
ess-environment. 

2. A computer system according to claim 1 
wherein said event-activity being implemented by 
inheriting features and capabilities of the class of 
activities or of a sub-class thereof according to the 



principles of object-orientation. 

3. A computer system according to any of abwe 
claims 

$ wherein said event-activity is associated witii 

an event, and 

wherein said event-activity may have associ- 
ated with it an input-container and/or an output-con- 
tainer, and 

10 wherein said event-activity may be ttie 

source and/or target of one or more control-connec- 
tors, and 

wherein said event-activity may be the 
source and/or target of one or more data-connec- 
ts tors, and 

wherein saki event-activity may be associ- 
ated vtnth a notification-mechanism allowing to 
freely define at least one action to be performed by 
the workftow-process-environment if said event- 
20 activity is not completed witiiin a freely defined time 
period. 

4. A computer system accorcRng to daim 3 
wherein sakJ event is implemented by an 

25 event-generator. 

5. A computer system accorcfing to daim 4 
wherein saki event-generator is imple- 
mented as a program. 

30 

6. A computer system according to anyone of daim 3 
toS 

wherein saki action automatfoally terminate 
saki event-activity. 

35 

7. A computer system according to any of above 
daims 

wtierein saki process-model encompassing 
at least one outgoing-oontrd-connector saki event- 
40 activity being the source and a target-activity toeing 
the target of saki outgoing-contrd-connector, and 

wherein saki outgoing-control-connector 
optionally may be associated witii a k>gical predi- 
cate as outgoing-transition-condition, and 
45 wherein said workfkw-process-environment 

activates said target-activity if saki event is signaled 
to said waiting event-activity arxi finally said 
eventactivity terminated and if saki outgoing-transi- 
tion-condftion evaluates to true. 

50 

8. A computer system according to any of above 
daims 

wherein said workftow-process-environment 
is activating said event-activity automatically when 
55 instantiating said process-model If said event-activ- 
ity is no target of a control-connector. 

9. A computer system according to daim 1 to 7 
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wherein said process-model encx>nipassing 
at least one incoming-control-connector said event- 
activity being the target and a source-activity being 
the source of said incoming-control-connector, arxJ 

wherein said incoming-control-connector 
optionally may t>e associated wrtii a logical predi- 
cate as incoming-transition-condition, and 

wherein said workf low-process-environment 
activates said e^nt-activity if said source-activity 
terminated arxJ said Incoming-transition-corKJition 
evaluates to true. 

10. A computer system according to claim 7 to 9 

wherein said workflow-process-environment 
registers said event-activity as awaiting consumer 
of said event once said event-activity is activated by 
said workf low-process-environment, and 

wherein further said workflow-process-envi- 
ronment registers said event as posted-event once 
the occunrence of said event is signaled by said 
event-generator. 

11 , A computer system according to claim 7 to 10 

wherein said target-activity is activated by 
said workfiow-process-environment if as a first con- 
dition said event-activity terminated and if as a sec- 
ond condition said outgoing-transition-condition 
evaluates to true independent at which point in time 
and in which sequence said first and said second 
concfition are fulfilled. 
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30 



wherein said workflow-navigator sends, if it 
detects tiiat said event-activity is awaiting for said 
event an awaited-event-notification to said event- 
monitor and if then said Gvent-nrx)nitor detects a 
matching posted-event-indication in saki posted- 
event-taWe sakI event-monitor indicates saki event 
togetiier with event-data to sakJ workflow-navigator 
or if othenaose no matching posted-event-notifica- 
tion is detected said event-monitor stores an 
awaited-event-indk»tion in sakJ awaited-event- 
table. arKi 

wherein sakJ event-generator indrcates the 
occunrence of sakJ event by a posted-event-indtea- 
tion to sakI event-monitor whteh verifies sakJ 
posted-event-indfcation by consulting sakf event- 
manager and then stores saki posted-event-irxlica- 
tion in saki posted-event-tabie and if then saki 
event-nxxiitDr detects a matching awaiting-event- 
indication in saki awaiting-event-table it indk^ates 
this togettier with eventKiata to saki workftow-navi- 
gator 

15. A computer system according to daim 14 

wherein said event-generator is informed, if 
said awaited-event-indication is stored in saki 
awaited-event-table. on this awaited-event-indica- 
tion. 



12. A computer system according to claim 10 encom- 
passing a workflow-navigator performing navigation 
of operation trough the process-graph of said proc- 
ess-model and saki computer system being furttier 3S 
characterized by 

an event-management-system extending and 
inter-operating with saki workflow-navigator. 
and ^ 



saki event-management-system encompasses 
the component of an event-monitor administer- 
ing awaited events in at least one awaited- 
event-table and further administering signaled 
events in at least one posted-event-table, and 
wherein saki event-generator is sigrtal- 
ing ttie occunrence of saki event to saki event- 
monitor. 

13. A computer system according to claim 12 

wherein said event-management-system 
encompasses the component of an event-manager 
maintaining information on saki event allowing to 
verify conrectness of said event if saki event is being 
signaled. 

14. A computer system according to claim 13 
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1 EVENT •Wait for Customer Response* 

2 EVENT_GENERATOR •MailCheckProgram' 

3 AUTOSTART 

4 NOTIFY 



FIG. 5 



1 EVENT ACTIVITY 'Wait for Response 

2 (• Event Identification*, 'Response Information ) 

3 EVENT 'Wait for Customer Response' 

4 END 'Wait for Response' 



FIG, 6 



1 EVENT ACTIVITY 'Wait for Response' 

2 ('Event Identification', 

3 'Response Information') 

4 EVENT 'Wait for Customer Response* 

5 NOTIFICATION 

6 AFTER 14 DAYS FORCE FINISH 

7 END 'Wait for Response' 

FIG. 7 



1 STRUCTURE 'Event Identification' 

2 'case number* : STRING ? 

3 'customer name' : STRING ; 

4 END 'Case Information' 

5 STRUCTURE ' Response information • 

6 'response ZU* s STRING ; 

7 'type' s STRING ; 
SEND 'I^etter Information' 

9 STRUCTURE 'Case Information' 

10 'case number • t STRING j 

11 •customer name' : STRING ; 

12 'response ID' s STRING ; 



FIG. 9 
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1 PROGRAM ACTIVITY 'Recjuest: Customer Info' 

2 (•Default Data Structure •Case Information') 

3 PRCX^RAM •RequestCustomerlnfo* 

4 END * Request Customer Info ' 

5 EVENT_ACTIVITY 'Wait for Reeponse* 

6 ('Event Identification', 

7 'Response Information') 

8 EVENT TYPE 'Wait for Customer Response' 

9 END 'Wait for Response* 

10 PROGRAM ACTIVITY 'Process Fax' 

11 ( • Case Information ' , • Def aultDataStructure ' ) 

12 PROGRAM 'Process Fax' 

13 END 'Process Fax' 

14 CONTROL FROM 'Request Customer Info' 

15 TO 'Wait for Response' 

16 CONTROL FROM 'Wait for Response' 

17 TO 'Process Fax' 

18 WHEN 'type = "FAX"' 

19 CONTROL FROM 'Wait for Response' 

20 TO 'Process Letter* 

21 WHEN 'type = "LETTER"' 

22 DATA FROM 'Request Customer Info' 

23 TO 'Wait for Response' 

24 DATA FROM 'Wait for Response' 

25 TO 'Process Fax' 

26 DATA FROM 'Request Customer Info' 

27 TO 'Process Fax' 

28 DATA FROM 'Wait for Response' 

29 TO 'Process Letter' 

30 DATA FROM 'Request Customer Info' 

31 TO 'Process Letter' 



FIG. 10 
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Events as activities in process models of workflow managennent systems 



(57) The present invention relates to the area of 
workflow management systems (WFMS). WFMS exe- 
cute a multitude of process models consisting of a net- 
work of potentially distributed activities. The cun-ent 
invention is dedicated to the implementation of events 
within WFMS. The cunent invention teaches to imple- 
ment events like any other process activity. 
Thus events are implemented as event-activities, a spe- 
cial type of an activity within said WFMS. Such an 
event-activity can manage an event oocuning internal or 
external to the WFMS. 

This approach allows to make all features available to 
common activities also accessible to event activities; 
examples are: input-container and/or output-container, 
control-connectors, data-connectors, notification-mech- 
anisms, predicates associated to control connectors 
forming transition conditions and many more. A control 
connector leaving an event activity, which optionally 
may be associated with a logcal predicate as outgoing 
transition condition, allows the WFMS to automatically 
activate a target activity if said event activity terminated 
after the event has been signaled to said event activity 
and if the outgoing transition condition evaluates to true. 
Similar an incoming control connector, whkih optionally 
may be associated with a logtoal predk^ate as incoming 
transition condition, allows a WFMS to automatically 
activate an event activity if the process activity being the 
source of said incoming control connector terminated 
and if said incoming-transition-condition evaluates to 



true. 

This inventfon also teaches to extend the navigator of a 
WFMS by an event management system which inter- 
operates with the navigator to deliver above mentioned 
functionality. The event management system encom- 
passes the component of an event monitor administer- 
ing awaited events in a awaited event table and further 
administering signaled events in a posted event table. 
The event management system further encompasses 
the component of an event manager maintaining infor- 
mation on events allowing to verify correctness of an 
event 
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